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Foreword 



rd , 



This Technical Report has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is a technical specification of the overall support of Multimedia Broadcast Multicast Service in 
UTRA. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] 3GPP TR 21.905: " Vocabulary for 3GPP Specifications ". 

[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1". 

[3] 3GPPTS 22.246: "MBMS User Services; Stage 1". 

[4] 3GPP TS 23.246: "Multimedia Broadcast Multicast Service; Architecture and Functional Description". 

[5] 3GPP TR 25.992: "Multimedia Broadcast Multicast Service (MBMS); UTRAN/GERAN Requirements". 

[6] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network 
(CN) nodes". 

[7] 3GPP TS 33.246: "3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)". 

[8] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 

3 Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply. 
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Figure 1 : MBMS Timeline, based on [4]. 

MBMS session start is the point at which the BM-SC is ready to send data. 

MBMS notification informs the UEs about forthcoming and about ongoing MBMS data transfer. 
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MBMS Cell Group is a group of multiple cells belonging to one RNS and sharing one PDCP and RLC entity to utilize 
p-t-m transmission of the MBMS Service 

MBMS session stop is the point at which the BM-SC determines that there will be no more data to send for some 
period of time. 

Data transfer is the phase when MBMS data are transferred to the UEs. 

MBMS service availability is the phase between start of service announcement and the end of the last session or stop 
of service announcement. 

MBMS lu data bearer denotes the data bearer estabhshed between SGSN and RNC to transport MBMS data 

MBMS radio bearer denotes the data bearer established between RNC and UE(s) to transport MBMS data 

MBMS RAB denotes both, the MBMS lu data bearer and the MBMS radio bearer 

MBMS Service Context contains the necessary information for the UTRAN to control the MBMS Service in UTRAN. 

MBMS lu signalling connection denotes the signalling connection established between the RNC and the CN node to 
serve one MBMS Service Context. 

MBMS Service Announcement: Mechanism to allow users to be informed about the MBMS services available [4] 

Pool area: see definition in ref.[6] 

MBMS Multicast Service Activation: see description in ref.[4] 

Critical Information: MBMS Neighbouring Cell Information, MBMS Radio Bearer Information and MBMS Service 
Information sent on MCCH. 

Non-critical information: MBMS Access Information sent on MCCH. 

MBMS Service Area: The area in which a specific MBMS Bearer Service is available. It is defined individually per 
MBMS Bearer Service. [4] 

3.2 Symbols 

(void) 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 21.905 [1] and the following apply: 

CELL_DCH 

CELL_FACH 

CG-Id Cell Group Identifier 

CRNC-Id CRNC Identifier 

FFS For Further Study 

MBMS Multimedia Broadcast Multicast Service 

MBMS service ID Multimedia Broadcast Multicast Service service Identity 

MBMS CG-Id MBMS Cell Group Identifier 

MBMS UCG-Id MBMS UTRAN Cell Group Identifier 

MCCH MBMS point-to-multipoint Control Channel 

MICH MBMS notification Indicator Channel 

MTCH MBMS point-to-multipoint Traffic Channel 

NI Notification Indicator 

p-t-p Point-to-Point 

p-t-m Point-to-Multipoint 

PF Probability Factor 

SNI Secondary Notification Indicator 
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Background and introduction 



The Introduction of the Multimedia Broadcast Multicast Service in UTRA describes techniques for optimised 
transmission of MBMS bearer service in UTRA such as point-to-multipoint transmission, selective combining and 
transmission mode selection between point-to-multipoint and point-to-point bearer. 

The Stage 1 MBMS service requirements are defined in [2] and MBMS Stage 1 user services are defined in [3]. 
UTRAN (and GERAN) requirements are covered in TR 25.992 [5]. The overall architecture, functional description and 
the reference architecture of MBMS are covered in TS 23.246 [3]. 



5 IVIBIVIS UTRAN and protocol architecture 

5.1 IVIBIVIS UTRAN architecture principles 
5.1 .1 MBMS Service Context in CRNC 

Each RNC-which is controlling one or several cells within an MBMS Service area maintains an MBMS Service 
Context for each MBMS service. 

1 Each CRNC MBMS Service Context is associated with an MBMS service ID. 

2 The CRNC MBMS Service Context contains a list of PMM connected mode UEs which are present in one or 
several cells of the CRNC and which have activated an MBMS service. The list includes at least the U-RNTI of 
the UEs. 

NOTE: The MBMS Service Context in the CRNC contains no information about RRC Idle mode UEs. 

3 The MBMS Service Context is created in the CRNC either 

if the SGSN informs the RNC that a UE has activated the MBMS Service in a cell controlled by the CRNC 
by the UE Linking procedure. In this case, the CRNC is the SRNC of the UE, 

or if the RNC is notified of an MBMS Session Start, 

- or if the RNC serves as a Drift RNC for a PMM-CONNECTED UE and receives for this UE a UE Link 
from the SRNC containing the MBMS Service Id of the concerned MBMS Service. 

4 Each RNC which is informed by the SGSN that a UE has activated one (or several) MBMS Service(s) by the 
UE Linking procedure maintains an MBMS Context for each indicated MBMS service, irrespectively of the 
MBMS Service Area. 

5 The MBMS Service Context is released by the CRNC either 

if the MBMS Service Context does not contain any UE information after a UE Unlinking procedure from a 
SGSN and there is no active MBMS Session for the concerned MBMS Service, 

or if the MBMS Service Context does not contain any UE Link at the time of a Session Stop 

or if the RNC receives a CN De-Registration for MBMS Service 

6 Associated functionalities: 

6.1 Bearer type selection for MBMS transmissions based on information in the CRNC MBMS Service 
Context. The decision process requires inter-working with Radio Resource Management and with the 
UE's SRNC in the case of p-t-p bearers. 

6.2 MBMS RB control for p-t-m bearers in each cell, based on information in the CRNC MBMS Service 
Context. 

6.3 Update of the MBMS Service Context when a PMM-CONNECTED UE, which has activated an 
MBMS Service, has entered a cell. Update of the MBMS Service Context via lur is performed by UE 
Linking. 
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6.4 Update of the MBMS Service Context when a PMM-CONNECTED UE, which has activated an 

MBMS Service, has left a cell. Update of the MBMS Service Context via lur is performed by UE Un- 
Linking. 

Note: For further details of UE linking via the lur interface see chapter 5.1.5. 

5.1 .2 MBMS Session start and MBMS Session Stop 

At MBMS Session Start and MBMS Session Stop the RNC receives a respective request from the CN. The MBMS 
Session Start Request shall contain the MBMS Service Id and MBMS Session Attributes (MBMS Service Area 
Information, QoS parameters, ...). The MBMS Session Start Request triggers the RNC to notify UEs, which have 
activated the MBMS Service of the MBMS Session Start. The MBMS Session Stop Request may trigger the RNC to 
notify UEs, which have activated the MBMS Service of the MBMS Session Stop. 

The MBMS Session Start and Session Stop procedures provide the setup and release of the MBMS RAB in the 
following way: 

The MBMS Session Start Request shall contain all information necessary to setup an MBMS RAB. When the RNC 
receives an MBMS Session Start Request, it typically executes MBMS lu data bearer set up and shall inform the 
sending CN node, of the outcome in the MBMS Session Start response message 

The RNC may not execute the MBMS lu data bearer setup for a given lu interface in case of lu-flex. In those cases the 
CN node shall be informed accordingly. 

In case of lu-flex, the RNC might receive more than one MBMS Session Start Request for an MBMS Service and shall 
not set up more than one MBMS lu bearer for a certain MBMS Service towards a pool area. 

When the RNC receives an MBMS Session Stop Request it shall release the associated MBMS RAB resources. 

The MBMS Session Start and Session Stop procedures serve to establish and release the MBMS lu signalling 
connection. 

5.1.3 MBMS lu bearer 

For each MBMS service, data is transferred via an MBMS RAB between the SGSN and the UE. For each MBMS 
service, data is transferred via one MBMS lu bearer between SGSN and the RNC in the whole MBMS Service area. 
Signalling messages specific for an MBMS Service are transferred via one dedicated MBMS lu signalling connection 
between the RNC and the SGSN. 

1 One MBMS lu bearer is established per MBMS service at MBMS Session Start. 

2 Regarding lu-flex the RNC shall not set up more than one MBMS lu bearer. 

3 Because of the dedicated channels and lur mobility, there is a need to send MBMS data to an RNC which is not 
necessarily part of the MBMS Service area. 

4 The MBMS lu bearer on lu is established per MBMS service and not per UE individually. 

5 Each PMM-CONNECTED mode UE with an activated MBMS service has its UE context bind to the MBMS lu 
bearer. 

6 There could be several MBMS RBs linked to one MBMS lu bearer (i.e. one MBMS lu bearer on lu maybe 
mapped to multiple DTCH and/or or p-t-m traffic channels over the radio -interface). 

5.1.4 MBMS lub bearer 

The existing EACH transport channel mechanism over lub is to be used in case of p-t-m MBMS transmission. 

5.1 .5 Mapping of MBMS lu bearer to p-t-p and p-t-m connections 

The service specific MBMS RAB on lu may be mapped to p-t-m bearers in order to provide MBMS data via common 
channels. 

1 The MBMS control function in the CRNC may decide to establish a p-t-m connection, if the number of counted 
MBMS users in a cell exceeds a certain operator-defined threshold. 
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2 The MBMS control function in the CRNC may decide to establish a p-t-m connection depending on the 
congestion scenario expected for a specific cell (e.g. in hotspot areas where no bearer type switching is needed). 

3 The MBMS control function in the CRNC may, through a configurable parameter enable/disable bearer type 
switching and the associated procedures on a per cell basis. 

4 The MBMS control function in the CRNC establishes an MBMS RB by sending service specific signalling 
messages (e.g. MBMS RB Setup message) to all the UEs in the cell listening MBMS point-to-multipoint 
control channel (MCCH). UEs with activated service(s) may then execute the RB set-up. 

5 MBMS data is transferred on a MBMS point-to-multipoint traffic channel (MTCH) to all the UEs which have 
executed the RB setup. 

6 The MBMS control function in the CRNC releases the MBMS RB (e.g. MBMS RB Release) when the data 

transfer has been finished or it has been interrupted by the CRNC. 

7 p-t-p transmission of MBMS data should use the DTCH as defined for other dedicated services. 

8 p-t-m transmission of MBMS data applies to all RRC states and modes. 



5.1.6 UE Linking 



UE Linking denotes the process where a UE, which has joined the MBMS service, is linked to an MBMS service 
context in the RNC. 

MBMS UE linking procedure in the SRNC is performed in following cases. 

1 . When the UE, which has joined the MBMS service, is moved to PMM-CONNECTED and sets up a PS RAB 
This may happen at any point in time during the whole MBMS service availability (i.e. before, during and 
between MBMS sessions). 

2. When the UE joins the MBMS service and is in PMM-CONNECTED due to an existing PS RAB. This may 
happen at any point in time during the whole MBMS service availability (i.e. before, during and between 
MBMS sessions). 

3. When the UE is moved to PMM-CONNECTED only for MBMS purpose, e.g. to respond to 
counting/recounting indication or respond to p-t-p bearer indication from RNC. This may happen at any point 
in time during MBMS sessions. 

Keeping UEs in PMM-CONNECTED only for MBMS between sessions is implementation specific. The UE linking in 
the SRNC is performed via UE dedicated lu procedures. An entry for the UE is added to the MBMS service context in 
the SRNC. If the MBMS service context doesn't exist yet it needs to be created. 

In case the UE consumes radio resources from a drift RNC, the UE Linking is performed via lur in the following way. 

1 . When the UE, which has activated one or several MBMS services, is in CELL_DCH or CELL_FACH state 
and starts to consume radio resources from one or several cells controlled by the DRNC, MBMS UE Linking 
in the DRNC is performed via UE dedicated lur procedures. 

2. If the UE is in CELL_DCH and CELL_FACH state and there is no dedicated RNL signalling activity ongoing 
for this UE and UE Linking is performed in the SRNC for an MBMS Service, MBMS UE Linking in the 
DRNC is performed via the MBMS Attach procedure. 

3. If the UE is in CELL_PCH and moves to a cell controlled by the DRNC, the MBMS UE Linking in the DRNC 
is performed. The cell the UE moved to is indicated to the DRNC. After that the MBMS Service context in the 
DRNC needs to be updated at every intra-DRNC cell change. 

4a. If the UE is in URA_PCH and moves to a URA which contain cell(s) that are controlled by the DRNC the UE 
is linked to the MBMS Service context in the DRNC. The URA the UE moved to will be indicated. The 
MBMS Service context in the DRNC needs to be updated at every intra-DRNC URA change. 

4b. As long as the SRNC serves UEs in URA_PCH in URAs containing cells controlled by another RNC, the 
SRNC shall keep this other RNC informed about every URA in which UEs having activated certain MBMS 
services have to be notified. This is done by indicating to the other RNC a list of URAs and the 
corresponding MBMS Services. 
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NOTEl : Whether the SRNC shall link all UEs in URA_PCH to the MBMS Service context in the DRNC for 
counting on URA basis is FFS. 

N0TE2: Bullet points 4a and 4b above may be merged in a future version of this document. 

5. If the UE is in CELL_PCH or URA_PCH and there is no mobility related signalling activity ongoing for this 
UE and UE Linking is performed in the SRNC for an MBMS Service, MBMS UE Linking in the DRNC is 
performed via the MBMS Attach procedure. 

6. If the UE is in CELL_PCH and leaves a cell controlled by the DRNC the UE is unUnked from the MBMS 
Service context in the DRNC via the MBMS Detach procedure. 

7. If the UE is in URA_PCH and leaves a URA containing cell(s) controlled by the DRNC the UE is unlinked 
from the MBMS Service context in the DRNC via the MBMS Detach procedure. 

8. If the UE is in RRC connected mode and UE Linking is performed in the SRNC for an MBMS Service and a 
session of this MBMS Service is ongoing UE Linking in the DRNC needs to be performed immediately. 

At MBMS UE linking in the DRNC the MBMS service context in the DRNC needs to be updated. If an MBMS service 
context does not exist yet then it shall be created. 



5.1.7 RNC Registration 



RNC Registration for a certain MBMS Service denotes the process where the CN becomes aware of an RNC hosting 
UEs, which have activated that MBMS Service. 

Due to UE mobility, a RNC with no MBMS Service Context, can be informed that a PMM-CONNECTED UE, which 
has entered the cell, has activated an MBMS Service by means of the MBMS UE Linking procedure via the lur 
interface. Then the RNC informs the CN that it would like to receive MBMS Session Start Request messages when 
applicable for the concerned MBMS Service by sending MBMS Registration Request message. 

It results in the set-up of a corresponding MBMS distribution tree, but it does not result in the establishment of lu user 
plane, which will be established by the MBMS Session Start procedure. 

1 . Implicit Registration 

RNC Registration for Serving RNCs is performed implicitly, i.e. due to UE linking and MBMS Multicast 
Service Activation. No explicit registration procedure needs to be performed. 

2. Explicit Registration 

RNC Registration for Drift RNCs is performed explicitly if an RNC becomes a Drift RNC for a UE, which 
has activated an MBMS service and has no MBMS Service Context for that MBMS Service. 

RNC Registration for Drift RNCs is performed explicitly if an RNC is no longer the SRNC of any 
connected UE which has activated an MBMS service, but hosts at least a UE which consumes radio 
resources of the RNC via lur. This shall happen only before sessions or between sessions. 

The DRNC will perform a registration towards its default CN node only. 

5.1.8 RNC De-Registration 

RNC De-Registration for a certain MBMS Service denotes the process where the CN becomes aware that an RNC 
registered at a CN node does not host any more PMM-CONNECTED UEs which have activated that MBMS Service. 

1 . Implicit RNC De-Registration 

RNC De-Registration for Serving RNCs is performed implicitly, i.e due to UE Unlinking and MBMS 
Multicast Service Deactivation. No explicit de-registration procedure needs to be performed. 

2. ExpUcit RNC De-Registration 

RNC De-Registration for Drift RNCs is performed explicitly if a RNC is not acting as a Serving RNC and 
has ceased to act as a Drift RNC for UEs which have activated an MBMS service, it will perform a de- 
registration towards the CN node it was registered to. 

The timing of RNC De-Registration is implementation specific. 
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NOTE: When the Drift RNC performes the explicit De-registration, the ImpUcit registration may still remain and 
in that case lu data bearer should not be removed. 

5.1.9 CN De-Registration 

CN De-Registration denotes the process where the CN informs the RNC that a certain MBMS service is no longer 
available. CN De-Registration should result in releasing of all associated MBMS Service Contexts and resources. 

The CN De-Registration procedure serves to release the MBMS lu signalling connection. 

5.2 MBMS Uu Principles 

5.2.1 IVIBIVIS Service States in UE 

The MBMS bearer service has following service states in the UE: 

1. Not active, UE has not joined any MBMS multicast service or not activated the broadcast mode of the MBMS 

2. Not active, UE has joined at least one MBMS multicast service and/or activated the broadcast mode of the 
MBMS, but MBMS SYSTEM INFORMATION is not broadcasted on BCCH. 

3. Active, UE has joined at least one MBMS multicast service and/or activated the broadcast mode of the MBMS, 
but any of the services that UE has joined (interested in broadcast mode) is not being transmitted. UE monitors 
MICH to find modifications in the MCCH as defined in 5.1.6 

4. Active; at least one MBMS multicast service which the UE has joined (interested in broadcast mode) is 
transmitted on p-t-m 

UE is receiving MBMS transmission on MTCH 

UE is using DRX based on scheduling information informing that coming MTCH transmission is not 
in the interest of the UE. 

5. Active; at least one MBMS multicast service which UE has joined is transmitted on p-t-p 

6. Active; at least one MBMS multicast service which UE has joined is transmitted on p-t-p and at least one 
MBMS multicast service which UE has joined (interested in broadcast mode) is transmitted on p-t-m. (only 
valid if UE has capability to support this combination) 

When MBMS transmission is started in cell the UE moves from state 3 to either state 4 or state 5 (6), depending on 
p-t-p transmission mode and after MBMS transmission ends in the cell, the UE moves from state 4 or state 5 (6) to state 
3. 

5.2.2 One PDCP and RLC entity sliared among multiple cells within one 
RNS 

For each MBMS service, a group of multiple cells belonging to one RNS shares one PDCP entity and RLC entity over 
p-t-m transmission. The group of multiple cells is called 'MBMS Cell Group'. 

1. There are one or more MBMS Cell Groups per MBMS service per RNS. The MBMS Cell Groups are 
managed by the CRNC. 

2. There are one or more cells pertaining to the same RNS for one MBMS Cell Group. 

3. For each MBMS service, the MBMS Cell Group Identifier (MBMS CG-Id) is used to uniquely identify a 
group of multiple cells sharing the same PDCP entity and RLC entity within an RNS. 

4. For each MBMS service, the MBMS CG-Id together with the identifier of the controlling RNC (CRNC -Id) 
constitutes the MBMS UTRAN Cell Group Identifier (MBMS UCG-Id). 

5. Each cell sends the MBMS UCG-Id to UEs for each MBMS service. The MBMS UCG-Id is used to uniquely 
identify an MBMS Cell Group in the UTRAN and UE. 
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5.2.3 MCCH Information Scheduling 



The MCCH information will be transmitted based on a fixed schedule. This schedule will identify the TTI containing 
the beginning of the MCCH information. The transmission of this information may take a variable number of TTIs and 
the UE will keep receiving the S-CCPCH until: 

It receives all of the MCCH information, or 

It receives a TTI that does not include any MCCH data, or 

The information contents indicate that further reception is not required (e.g. no modification to the desired 
service information). 

Based on this behaviour, the UTRAN may repeat the MCCH information following a scheduled transmission in order to 
improve reliability. The MCCH schedule will be common for all services. 

The entire MCCH information will be transmitted periodically based on a "repetition period". The "modification 
period" will be defined as an integer multiple of the repetition period. The MBMS ACCESS INFORMATION may be 
transmitted periodically based on an "access info period". This period will be an integer divider of the "repetition 
period". 

MCCH information is split into critical and non-critical information. The critical information is made up of the MBMS 
NEIGHBOURING CELL INFORMATION, MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION. The non-critical information coiTesponds to the MBMS ACCESS INFORMATION. Changes to 
critical information will only be applied at the first MCCH transmission of a modification period. Changes to non- 
critical information could take place at any time. 

The Figure 2 below illustrates the schedule with which the MBMS SERVICE INFORMATION and RADIO BEARER 
INFORMATION would be transmitted. Different colours indicate potentially different MCCH content. 
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I I I 



MCCH i-^ ^ Repetition period 
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Figure 2: MCCH Information Schedule 

5.2.4 MBMS Notification 

NOTE: This section describes only the case that the MBMS notification indicators are sent on MICH. 

An MBMS notification may also be sent on the S-CCPCH carrying the MTCH or even on the S-CCPCH carrying the 
MCCH. Thus UTRAN may use in-band notification instead of the MICH to notify users receiving MTCH. [FFS based 
on decision on SNI]. 

The MBMS notification mechanism is used to inform UEs of an upcoming change in critical MCCH information. 
Notifications are based on service groups. The mapping between service IDs and service groups will be based on a 
hashing mechanism. The exact details of this mechanism will be defined in the Stage 3 specifications. 

The MBMS notification indicators will be sent on an MBMS specific PICH, called the MICH. A single MICH frame 
will be able to carry indications for every service-group. 

Critical MCCH information can only be changed at the beginning of a modification period as described in Section 5.2.3. 
The MBMS notification indicator corresponding to the service group of every affected service shall be set continuously 
during the entire modification period preceding the first change in MCCH information related to a given service. 
Subsequent changes in the MCCH information in the next modification period related to the same service can be 
signalled on the MCCH. 
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UEs are free to read the MBMS notification at any time; however the modification interval shall be long enough so that 
UEs are able to reliably detect it even if they only receive the MICH during their regular Release 99 paging occasions. 
The need to limit particularly long DRX cycles (e.g. 5 sec) due to MBMS reception is defined in Stage 3. 

Upon detecting the MBMS notification indication for a service group, UEs interested in a service corresponding to this 
group shall start reading the MCCH at the beginning of the next modification period. 

The Figure 3 below illustrates the timing relation between the setting of the MICH and the first MCCH critical 
information change. The green colour for the MICH indicates when the NI is set for the service. For the MCCH, 
different colours indicate MCCH content related to the notification of different services. 
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Figure 3: Illustration of MICH timing relative to Modification period 



5.2.5 MBMS Counting 



MBMS Counting is used to determine the optimum transmission mechanism for a given service. 

1 . The need for counting is indicated in the notification, and achieved by requesting UEs, belonging to the same 
MBMS service group, to establish an RRC connection. 

2. The exact number of UEs that need to be brought to RRC connected mode is an RRM issue. 

3. Since it is desirable in a specific cell, to avoid bringing a large number of UEs for counting purposes to RRC 
connected mode at the same time (RACH load, etc), RRM may control the load due to the RRC connection 
establishment requests, by setting an access "probability factor". 

4. Following counting, the number of subscribers that need to be maintained in RRC connected mode or for 
which the RNC releases their connection, is also an RRM issue. 

5. For a given MBMS service, the counting indication in the notification may be switched on and off, on per-cell 

basis. 

6. The RNC may use notification to indicate counting during an ongoing MBMS session (term used is re- 
counting). 

7. The RNC receives via lu from CN information (MBMS service ID) about UEs who are in RRC Connected 
mode, and have joined the MBMS service. This information may be used for counting purposes. 

The MBMS counting function includes a mechanism by which the UTRAN can prompt users interested in a given 
service to become RRC connected. This procedure is only applicable for UEs in idle mode and relies on the MBMS 
ACCESS INFORMATION transmitted on the MCCH. The probability factor indicates the probabihty with which UEs 
need to attempt an RRC connection procedure. 

In order to trigger counting for a given service, the UTRAN may use the regular MBMS notification mechanism 
outlined in section 5.2.4 to force UEs interested in the service to read the MCCH information. 
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Once a UE detects that the counting procedure is on-going for the specific service it wants to receive, it will attempt to 
set up an RRC connection based on the probability factor included in the MCCH. [The details of this mechanism will be 
defined in the Stage 3 specifications]. 

A UE in URA_PCH state which is notified on the MCCH shall initiate a cell update procedure with a specific cause 
based upon the information provided in the MBMS ACCESS INFORMATION. 

Also, the UE will keep receiving the MBMS ACCESS INFORMATION at every access info period until UE becomes 
RRC connected or counting is no longer required. Whenever it receives new MBMS ACCESS INFORMATION the UE 
will update its probability factor with the new value. 

The Figure 4 below illustrates this mechanism. The green colour for the MICH indicates when the NI is set for the 
service. The green colour for the MBMS ACCESS INFORMATION indicates that the counting procedure is on-going 
and that UEs need to establish an RRC connection based on the included probability factor (PF). For the critical MCCH 
info, different colours indicate potentially different content. 
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Figure 4: Illustration of Access Info period during MBMS counting 

For every UE brought to RRC connected state for the purpose of counting, UTRAN will initiate the PMM Connection 
establishment procedure and will obtain from CN the set of MBMS services these users have joined. 

Counting for on-going services (re-counting) will rely on the same scheduling of the MCCH information. The only 
difference is that UTRAN may use in-band notification instead of the MICH to notify users [FFS based on decision on 

SNI]. 

5.2.6 MBMS Radio Bearer Release in tine UE 

The UE releases the MBMS RB by using one of the following mechanisms: 

- Exphcit MBMS RB Release 

- Implicit MBMS RB Release 

The Explicit MBMS RB Release mechanism allows UTRAN to explicitly indicate to MBMS UEs that an MBMS Radio 
Beai-er should be released. The Explicit MBMS RB Release indication is included in a new MBMS RADIO BEARER 
RELEASE information, the existing MBMS SERVICE INFORMATION, MBMS RADIO BEARER INFORMATION 
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or the existing RADIO BEARER RELEASE message. If the Exphcit MBMS RB Release indication is received, the UE 
releases the MBMS RB. 

The Implicit MBMS RB Release mechanism allows is only used for p-t-m transmission and a UE to release the MBMS 
Radio Bearer without receiving the MBMS RB release message given from UTRAN as follows: 

A UE uses a timer to implicit release of the MBMS RB. The timer value is given from UTRAN. 



5.3 



Protocol structure 



5.3.1 MBMS User Plane Protocol Stack Architecture 
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Figure 5: Protocol Stack for MICH 

Figure 5 illustrates the protocol termination for MTCH in MBMS, which is used in p-t-m transmission. 

PDCP sub-layer performs header compression/decompression for the MBMS traffic. 

PDCP sub-layer may operate with RFC 3095 header compression protocol. In that case, header compression should be 
performed under RFC 3095 U-mode. 

In the UTRAN side, there is one PDCP entity per cell supporting MBMS or MBMS Cell Group for each MBMS service 
in each RNS. The shared PDCP entity in the UTRAN duplicates all PDCP PDUs to every RLC entity for every cell 
belonging to one MBMS Cell Group. 

In the UTRAN, there is one RLC entity for each MBMS service in each cell or cell group in case of utilization of 
selective combining or maximum ratio combining in TDD, and one MAC entity for each cell. 

In the UE side, there is one PDCP and RLC entity for each MBMS service in each UE. In each UE there is one MAC 
entity per received cell when UE is performing the selective combining between these cells. 

In case of p-t-p transmission, DTCH is used for MBMS transmission and the protocol termination for DTCH mapped 
on DCH and RACH/FACH are presented in [8]. 
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5.3.2 MBMS Control Plane Protocol Stack Architecture 
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Figure 6: Protocol Stack for MCCH 

Figure 6 illustrates the protocol termination for MCCH in MBMS, which is p-t-m control channel. 

MBMS functionalities are included in MAC and RRC. 

In case of p-t-p transmission, DCCH is used for MBMS and the protocol termination for DCCH mapped on DCH and 
FACH are presented in [8]. 



5.4 



MAC architecture 



5.4.1 UTRAN IVIAC Architecture to support MBMS 



MAC Control 



MCCHPCCHBCCH MTCH MTCHCCH CTCH SHCCH MAC Control 



c> 




I I 

Configuraition^ I 



without N|AC -c|sh 



MAC-hs 



Configuration 
with MAC-c/sh 



C oiifigu: ation 
tJiM; C-c/sh 



MAC-c/sh/m 



HS-DSCH HS-DSCH 




ssociated I 
ignalling 



Associated Uplink 
Signalling 



1 \ — n — \ — r 

PCH FACH FACH RACH CPCH USCH USCH DSCH DSCH 

FDD only TDD only TDD unly 



Figure 7: UTRAN MAC architecture 
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To support MBMS user and control plane transmission, a multicast functionality is added in the MAC c/sh, entitled 
"MAC m", to take care of scheduling of MBMS related transport channels as presented in Figure 7. In addition, two 
logical channels are considered for p-t-m transmission of MBMS: MCCH and MTCH. Both logical channels are 
mapped on FACH. In case of p-t-p transmission DTCH and DCCH are used. 

5.4.2 MAC-c/sh/m architecture: UTRAN side 

Figure 4 illustrates the MAC-m additions to the MAC-c/sh architecture in the UTRAN side, needed to transmit MBMS 
data over a common transport channel (FACH). 
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MAC-c/sh/m is located in the controlling RNC. The following functionahties are covered: 

Scheduling / Buffering / Priority Handling: This function manages common transport resources between 
MBMS and non-MBMS data flow(s) according to their priority. 

TCTF MUX: This function handles insertion of the TCTF field in the MAC header and also the respective 
mapping between logical channels (i.e. MTCH and MCCH) and transport channels. The TCTF field 
indicates which type of logical channel (i.e. MTCH and MCCH) is used. 

Addition of MBMS-ID: For p-t-m type of logical channels, the MBMS-ID field in the MAC header is 
used to distinguish between MBMS services. 

TFC selection: Transport format combination selection is done for a common transport channel (FACH) 
mapped to MTCH and MCCH. 

There is one MAC-c/sh/m entity in the UTRAN for each cell. 
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Scheduling/Buffering/ Priority Handling 
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TFC selection 



MAC-c/sh/m 
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Figure 8: UTRAN side IVIAC-m archiitecture additions to lUIAC-c/shi 

5.4.3 MAC-c/sh/m architecture: UE side 

Figure 5 illustrates the MAC-m additions to the MAC-c/sh architecture in the UE side, needed to receive MBMS data 
over a transport channel (FACH). 

The following functionalities are covered: 

TCTF DEMUX: This function handles detection and deletion of the TCTF field in the MAC header, and 
also the respective mapping between logical channels (i.e. MTCH and MCCH) and transport channels. 
The TCTF field indicates which type of logical channel (i.e. MTCH and MCCH) is used. 

Reading of MBMS-ID: The MBMS-ID idendfies data to a specific MBMS service. 

There are one or several (in case of selective combining) MAC-m entities in each UE. 
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Figure 9: UE side lUIAC-m additions to IVIAC-c/sh 



6 MBMS Channel Structure 

There exists two transmission modes to provide the MBMS service; 
Point-to-point transmission (p-t-p) 
Point-to-muhipoint transmission (p-t-m) 



6.1 



Point-to-Point Transmission 



Point-to-point transmission is used to transfer MBMS specific control/user plane information as well as dedicated 
control/user plane information between the network and one UE in RRC Connected Mode. It is used only for the 
multicast mode of MBMS. 

For a UE in CELL_FACH and Cell_DCH, DCCH or DTCH is used, allowing all existing mappings to transport 
channels. 

A detailed description of channels used for point-to-point transmission is given in [8]. 

6.2 Point-to-multipoint Transmission 

Point-to-multipoint transmission is used to transfer MBMS specific control/user plane information between the network 
and several UEs in RRC Connected or Idle Mode. It is used for broadcast or multicast mode of MBMS. 

6.2.1 Logical Channels 

6.2.1 .1 MBMS point-to-multipoint Control Channel (MCCH) 

This logical channel is used for a p-t-m downlink transmission of control plane information between network and UEs 
in RRC Connected or Idle Mode. The control plane information on MCCH is MBMS specific and is sent to UEs in a 
cell with an activated (joined) MBMS service. MCCH can be sent in S-CCPCH caiTying the DCCH of the UEs in 
CELL_FACH state, or in standalone S-CCPCH, or in same S-CCPCH with MTCH. Short indication is always given to 
UE to when to read MCCH. UTRAN may use in-band notification instead of the MICH to notify users receiving 
MTCH. [FFS based on decision on SNI]. 

Reception of paging has priority over reception of MCCH for Idle mode and URA/CELL_PCH UEs. 
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6.2.1 .2 MBMS point-to-multipoint Traffic Channel (MTCH) 

This logical channel is used for a p-t-m downlink transmission of user plane information between network and UEs in 
RRC Connected or Idle Mode. The user plane information on MTCH is MBMS Service specific and is sent to UEs in a 
cell with an activated MBMS service. 

6.2.2 Transport Channel 

FACH is used as a transport channel for MTCH and MCCH. 

6.2.3 Physical Channel 

SCCPCH is used as a physical channel for FACH carrying MTCH or MCCH. 

6.2.4 Mapping between channels 

Only in downlink, the following connections between logical channels and transport channels exist: 

- MCCH can be mapped to FACH 

- MTCH can be mapped to FACH 

The mappings as seen from the UE and UTRAN sides are shown in Figure 10 and Figure 1 1 respectively. 
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Figure 10: Logical channels mapped onto transport channel, seen from the UE side 
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Figure 11 : Logical channels mapped onto transport channel, seen from the UTRAN side 
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6.2.5 Data Flows through Layer 2 

6.2.5.1 Data flow for MCCH mapped to FACH 

For MCCH, the RLC mode to be employed is UM-RLC, with required enhancements to support out of sequence SDU 
deHvery. A MAC header is used for logical channel type identification. 

6.2.5.2 Data flow for MTCH mapped to FACH 

For MTCH, the RLC mode to be employed is UM-RLC, with required enhancements to support selective combining. 
Quick repeat may be used in RLC-UM. A MAC header is used for logical channel type identification and MBMS 
service identification. 

6.3. MBMS Notification Indicator Channel 

MBMS notification utilizes a new MBMS specific PICH called MBMS Notification Indicator Channel (MICH) in cell. 
The exact coding is defined in Stage-3 physical layer specifications. 



7 IVIBIVIS Reception and UE Capability 

7.1 Selective Combining for MBMS P-T-M transmission 

The selective combining for MBMS p-t-m transmission is supported by RLC PDU numbering. Therefore, the selective 
combining in the UE is possible from cells providing similar MBMS RB bit rate, provided that the de-synchronization 
between MBMS p-t-m transmission streams does not exceed the RLC re-ordering capability of the UE. Thus, there exist 
one RLC entity in the UE side. 

To support selective combining it is decided to: 

Introduce re-ordering as a configurable feature of RLC-UM, within the RLC specification. 

Use the same mechanism as what is specified for MAC-hs (single Tl timer). 

For selective combining there exist one RLC entity per MBMS service utilizing p-t-m transmission in the cell group of 
the CRNC. All cells in the cell group are under the same CRNC, i.e. lur support is not considered. 

The UE capability requirements to support selective combining are defined in chapter 7.2. In case de-synchronization 
occurs between MBMS transmissions in neighbouring cells belonging to an MBMS cell group the CRNC may perform 
re-synchronization actions enabling UEs to perform the selective combining between these cells. 

For TDD, selection combining and the maximum ratio combining can be used when Node-Bs are synchronized 

When selective combining is available between cells the UTRAN should send MBMS NEIGHBOURING CELL 
INFORMATION containing the MTCH configuration of the neighbouring cells, available for selective combining. 
With MBMS NEIGHBOURING CELL INFORMATION the UE is able to receive MTCH transmission from 
neighbouring cell without reception of the MCCH of that cell. 

The UE determines the neighbouring cell suitable for selective combining based on threshold (e.g. measured CPICH 
Ec/No) and the presence of MBMS NEIGHBOURING CELL INFORMATION of that neighbour cell. 

The possibility of performing selective combining should be signalled to the UE. 



7.1 .bis Simulcast Combining (TDD only) 



In contrast to FDD, downlink macro diversity has not been a characteristic of TDD during release '99/4/5. As such 
TDD receivers are not typically designed to facilitate the simultaneous reception of multiple radio links and the 
incorporation of such a requirement for MBMS in TDD would have non-trivial impacts on the receiver design. 
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Much of the receiver complexity increase associated with the combining of muhiple radio Hnks in the UE can however 
be avoided in TDD by combining macro-diversity with timeslot re-use. This also allows for the throughput gains from 
timeslot re-use to be combined with further gains from macro diversity. 

In such a scheme, the transmissions of the same information from the multiple participating cells are arranged such that 
they arrive at the UE on substantially different timeslots, thereby removing the requirement at the UE to detect multiple 
cells in the same timeslot. 

As such, cells are partitioned into transmission "groups" or "sets". Each transmission set is allocated a timeslot (or set 
of timeslots) for MBMS transmission. The assigned slots are typically exclusively used by that MBMS set; sets do not 
transmit when another set is active. The UE attempts to receive information from each set and to combine them either 
at the physical layer or RLC layer in order to enhance reception reliability. 

Figure 12 shows such a scheme applied to a tri-sectored deployment model. 3 timeslots (ti, t2 and tj) are allocated to 
each sector for the purposes of MBMS transmission. Each sector is assigned to a particular "MBMS transmission set", 
set 1, 2 or 3. 

An MBMS data unit or transport block is encoded over several radio frames (eg: 80ms TTI). The physical channel bits 
that result are effectively transmitted three times; once by MBMS set 1 in timeslot tj, once by MBMS set 2 in timeslot 
t2, and once by MBMS set 3 in timeslot t3. 
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Figure 12: Example of non-time-coincident macro diversity transmission 

A given UE may be configured to listen to the separate transmissions of the MBMS physical channels (one from each 
set) which, over the course of the TTI, correspond to the MBMS transport block(s). The signals from each MBMS set 
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are largely non-time-coincident and do not require the use of an extensively modified receiver architecture -a receiver 
architecture resembling that of a normal "single-radio-link" TDD receiver may be used. 

The received transport blocks may be provided to the RLC layer for selective combining, or soft information may be 
buffered and combined across MBMS sets during the course of the TTI via physical layer maximum ratio combining . 

The UTRAN shall signal to the UE on the MCCH which services may be maximum ratio combined (and in which 
cells). The cell group for maximum ratio combining may be different than the cell group for selective combining. The 
UE may assume that transmissions of a given service that may be maximum ratio combined take place in the same 
frame. 



7.2 UE Capability 



The UE MBMS capability is not sent to UTRAN and is subject to UE implementation, including the relation between 
MBMS capability and actual RRC state which is also a UE implementation. A consequence is that a UE may be 
counted although its actual capability does not allow to receive MBMS transmissions e.g. because of its current RRC 
state. Further optimizations to avoid counting of useless UEs maybe included in Stage 3. 

The standard will describe a minimum UE capability requirement in order to allow operators to configure MBMS 
channels that can be common to all UEs supporting the given service. 

There are some UE capability requirements that are common to all eventual service categories: 

The minimum UE capability for MBMS capable UE, is one primary CCPCH plus all the configurations below. The UE 
is not required to support these configurations simultaneously. 

1 . One PICH and one MICH 

2. One S -CCPCH and one MICH 

3. One S -CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and two S-CCPCH with 
80ms TTI for MTCH reception 

4. One S-CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and three S-CCPCH with 
40ms TTI for MTCH reception 

5. One PICH and two S-CCPCH with 80ms TTI for MTCH reception 

6. One PICH and three S-CCPCH with 40ms TTI for MTCH reception 

The requirement one reflects the case when the UE is in Idle mode, or URA_PCH, CELL_PCH state and MBMS 
reception is not ongoing and requirement five and six are for the case that MBMS reception is ongoing in Idle mode, or 
URA_PCH, CELL_PCH state. 

The requirement two reflects the case when the UE is in CELL_FACH state and MBMS is reception not ongoing and 
requirement three and four are for the case when MBMS reception is ongoing respectively. 

The abihty of the UE to receive DPCH/HS-PDSCH simultaneously with S-CCPCH carrying MTCH/MCCH is subject 
to UE capability. 

The minimum MBMS bit rate that all MBMS capable UEs shall support is to be defined in Stage 3. 

For FDD, the UE shall support selective combining and may support soft combining (signalling support will be 
needed). For TDD, the UE shall support both selective and maximum ratio combining. 

The standard may restrict further the UE implementation options by defining certain capability combinations. 

7.3 IVIBIVIS Reception 

The following descriptions add MBMS specific processes to be considered for each RRC State/Mode. 
The BCCH contains information regarding the MCCH, while the latter contains information on the MTCH. 
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In the sub-sections below, how and when the UE reads the MCCH is not described as periodic MCCH transmission is 
described in 5.2.3. . 

NOTE: reception of multiple MBMS services simultaneously is subject to UE capability; selection between these when 
needed is [FFS]. 

7.3.1 MBMS Reception in RRC Idle Mode 

In idle mode, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH and: 

- if the MBMS service requires the establishment of an RRC Connection 

- inform upper layers that the MBMS Service requires the establishment of an RRC Connection, 

- if the MBMS service does not require the establishment of an RRC Connection : 

- listen to the common transport channel on which the MTCH is mapped. 

- if the UE determines that a neighbouring cell is suitable for selective combining and the UE has valid MBMS 

NEIGHBOURING CELL INFORMATION of that cell: 

- performs selective combining of MTCH between the selected cell and the neighbouring cell. 

7.3.2 MBMS Reception in RRC Connected Mode: URA_PCH state 

In URA_PCH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the URA where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH, 

- if on the MCCH is indicated that the MBMS service in the cell requires a cell update: 

- initiate a cell update procedure. The cause to be used in the cell update procedure is defined in Stage 3. 

- for each MBMS service that the UE has activated and where transmission on a MTCH is indicated in the 

MCCH, listen to the common transport channel on which the MTCH is mapped, 

- if the UE determines that a neighbouring cell is suitable for selective combining the UE has valid MBMS 

NEIGHBOURING CELL INFORMATION of that cell 

- performs selective combining of MTCH between the selected cell and the neighbouring cell. 



7.3.3 MBMS Reception in RRC Connected Mode: CELL_PCH state 

In CELL_PCH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH 
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- listen to the common transport channel on which the MTCH is mapped, 

- if the UE determines that a neighbouring cell is suitable for selective combining the UE has valid MBMS 

NEIGHBOURING CELL INFORMATION of that cell 

- performs selective combining of MTCH between the selected cell and the neighbouring cell. 

7.3.4 MBMS Reception in RRC Connected Mode: CELL_FACH state 

In CELL_FACH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH 

- listen to the common transport channel on which the MTCH is mapped 

- if the UE determines that a neighbouring cell is suitable for selective combining the UE has valid MBMS 

NEIGHBOURING CELL INFORMATION of that cell 

- performs selective combining of MTCH between the selected cell and the neighbouring cell. 
NOTE: For UEs in CELL_FACH, UTRAN may decide to send MBMS data over DTCH. 

7.3.5 MBMS Reception in RRC Connected Mode: CELL_DCH state 

In CELL_DCH, the UE shall, 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available and 

- if the UE has the capabilities: 

- act on RRC messages received on MCCH 

- listen to the common transport channel on which the MTCH is mapped. 

- if the UE determines that a neighbouring cell is suitable for selective combining the UE has valid MBMS 

NEIGHBOURING CELL INFORMATION of that cell and UE has capability 

- performs selective combining of MTCH between the selected cell and the neighbouring cell. 
NOTE: For UEs in CELL_DCH, UTRAN may decide to send MBMS data over DTCH 



8 UTRAN Signalling Flows for MBMS 

8.1 MBMS Higin Level Signalling Scenarios 

This subclause includes descriptions for a number of aspects for which the solution has not been agreed. This 
relates at least to the following open issues that are not agreed: 

• Use of notification indicators for cases other than session start [This open issue is marked also in 
Chapters 5.2.4 MBMS Notification and 5.2.5 MBMS Counting] 
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• The use of the Secondary Notification Indicator (SNI), including its contents and its mapping [This open 
issue relates to previous one and is marked also in Chapters 5.2.4 MBMS Notification and 5.2.5 MBMS 
Counting] 

Even when not explicitly marked as FFS, the descriptions included in this subclause relating to the issues listed 
above should be considered as just one possible approach. 

8.1.1 Session start 

Upon receiving a session start indication from CN, UTRAN initiates the session start sequence to allocate radio 
resources to UEs for receiving the MBMS content. As part of this sequence, UTRAN may apply the counting procedure 
(counting the number of idle mode UEs) to decide whether to use the p-t-m or p-t-p transfer mode. 

The Figure 13 shows an example of a possible session start sequence. 



UE 



UTRAN 



1 . Notification for session start 



2. IVIBIVIS RB (IVITCH, DTCH) establisliment 



3. IVIBIVIS data transfer 



Figure 13: Session start 

In general, the session start sequence involves the following steps: 

• In case UTRAN applies counting to determine the most optimal transfer mode, it may first apply conventional 
paging to move UEs in URA_PCH to CELL_PCH state. Next, the following steps are performed: 

o UTRAN sets the coiTect MBMS Notification Indicator (NI) and sends the MBMS ACCESS 
INFORMATIONincluding service ID, and access probability on MCCH. 

o Upon DRX wakeup, UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH not 
receiving an MBMS service provided in p-t-m transfer mode evaluate the MBMS NI and if set, read 
MCCH at the pre- defined time(s). Upon receiving the MBMS ACCESS INFORMATION including 
access probability, UEs in idle mode for which the probability check passes, initiate RRC connection 
establishment to move to PMM CONNECTED. RRC Connected mode UEs ignore the MBMS ACCESS 
INFORMATION. UTRAN counts the UEs interested in the MBMS service using UE Unking from CN 

o In case a pre- defined threshold is reached, UTRAN applies the p-t-m RB establishment procedure 
specified below. Otherwise, UTRAN may repeat the MBMS ACCESS INFORM ATIONa number of 
times, using different probability values. If the threshold is not reached, UTRAN applies the p-t-p RB 
establishment procedure 

NOTE: The NIs are evaluated by UEs in CELL_PCH, URA_PCH and CELL_FACH that are not receiving an 

MBMS service that is provided using p-t-m transfer mode. In this section these UEs are referred to as 'NI- 
detecting connected mode UEs'. The UEs in CELL_PCH, URA_PCH, CELL_FACH and CELL_DCH 
that are receiving an MBMS service that is provided using p-t-m transfer mode receive the Secondary 
Notification Indicator (SNI) instead. The latter UEs are referred to as 'SNI detecting connected mode 
UEs'. 

• In case UTRAN selects the p-t-m RB establishment procedure: 
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o UTRAN configures MTCH and updates MCCH (MBMS SERVICE INFORMATION and MBMS 
RADIO BEARER INFORMATION) by including the service ID and p-t-m RB information for the 
concerned MBMS service 

o In case p-t-m RB establishment is not preceded by counting, UTRAN sets the correct MBMS Notification 
Indicator (NI). Regardless of counting, UTRAN also provides the Secondary Notification Indicator. 

o UTRAN sends the MBMS dedicated notification message including the service ID and cause= session 
start on DCCH to inform UEs in CELL_DCH that are not receiving an MBMS service provided using p-t- 
m transfer mode 

o In case p-t-m RB establishment is preceded by counting, UEs in idle mode as well as NI- detecting 
connected mode UEs read MCCH at the pre- defined time(s) to acquire the MBMS SERVICE 
INFORMATION and MBMS RADIO BEARER INFORMATION 

o In case p-t-m RB establishment is not preceded by counting. Upon DRX wakeup, UEs in idle mode as 
well as NI- detecting connected mode UEs evaluate the MBMS NI and if set, read MCCH at the pre- 
defined time(s)to acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION 

o Upon detecting the MBMS SNI, SNI- detecting connected mode UEs read MCCH at the pre- defined 
time(s) to acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION. UEs that are incapable of receiving the MTCH for the session that is started in parallel 
to the existing activity notify the user. This enables the user to choose between the ongoing activity and 
the new MBMS service 

o Upon receiving MBMS dedicated notification with cause= session start, UEs in CELL_DCH that are 
incapable of receiving the MCCH and the corresponding MTCH in parallel to the existing activity notify 
the user. This enables the user to choose between the ongoing activity and the new MBMS service. If the 
user decides to receive the new MBMS service, the UE shall read MCCH at the pre- defined time(s) to 
acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION. 

o Upon receiving the MBMS SERVICE INFORMATION and the MBMS RB INFORMATION including 
the p-t-m RB information for the concerned MBMS service, the UE starts receiving the p-t-m radio 
bearers 



• 



In case UTRAN selects the p-t-p RB establishment procedure: 

o UTRAN applies conventional paging to trigger UEs in CELL_PCH to perform cell update. Furthermore, 
UTRAN establishes the p-t-p RB by means of appropriate RRC procedures eg. the RB setup procedure 

o UEs establish the p-t-p radio bearers by means of the RRC procedure selected by UTRAN eg. the RB 
setup procedure 

o UTRAN updates MCCH (MBMS SERVICE INFO) to inform UEs joining or entering the cell at a later 
point in time. 



8.1 .2 Joining (during a session) 



In case the user wants to join an MBMS service (before or during a session), the UE initiates NAS procedures (e.g. 
MBMS service activation). 

If no session is ongoing upon completion of the joining procedure, the joining procedure is transparent to the AS. 

In case a session using p-t-m transfer mode is ongoing upon completion of the joining procedure, the UE may initiate 
reception of the p-t-m radio bearers. In case the ongoing session applies p-t-p transfer mode, UTRAN may establish the 
p-t-p radio bearers. UTRAN would do this upon receiving a UE linking indication from CN, which normally follows 
the joining. As a result of the UE linking, UTRAN may decide to change the transfer mode from p-t-p to p-t-m. This 
change of transfer mode is out of the scope of this sequence (to be covered by a separate sequence). 

The Figure 14 shows an example of a possible joining sequence. 
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UE 



UTRAN 



1. Joining (NAS) 



2. Initiate reception of PTIVI RBs 



3. IVIBIVIS data transfer, PTM 



Figure 14: Joining with continuation of p-t-m 

In general, the joining sequence involves the following steps: 

• UEs in idle mode first perform RRC connection establishment, while UEs in CELL_PCH and URA_PCH first 
perform cell update 

• UEs initiate the joining procedure (NAS) 

• In case UTRAN continues to use the p-t-m transfer mode: 

o UTRAN sends the MBMS dedicated notification message on DCCH including the service ID and cause= 
session ongoing to inform UEs in CELL_DCH 

o Upon receiving MBMS dedicated notification with cause= session ongoing, UEs in CELL_DCH that are 
incapable of receiving the MCCH and the corresponding MTCH in parallel to the existing activity notify 
the upper layer. This enables the user to choose between the ongoing activity and the new MBMS service. 
If the user chooses to receive the new MBMS service or if the UE in Cell_DCH is capable of receiving 
MCCH and MTCH in parallel to the existing activity, the UE shall read MCCH at the pre- defined time(s) 
to acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION from 
MCCH. 

o Upon acquiring the MBMS SERVICE INFORMATION and the MBMS RADIO BEARER 

INFORMATION including the p-t-m RB information for the concerned MBMS service, the UE starts 
receiving the p-t-m radio bearers 

• In case UTRAN continues using the p-t-p transfer mode: 

o UTRAN establishes the p-t-p RB by means of appropriate RRC procedures eg. the RB setup procedure 

o UEs establish the p-t-p radio bearers by means of the RRC procedure selected by UTRAN eg. the RB 
setup procedure. 

8.1.3 Recounting 

During a p-t-m MBMS session, UTRAN may perform re- counting to verify if p-t-m is still the optimal transfer mode. 
The purpose of the re- counting procedure is to count the number of idle mode UEs that have joined a specific service. 
As a result of this procedure, UTRAN may decide to change the transfer mode from p-t-m to p-t-p. This change of 
transfer mode is outside the scope of this sequence (to be covered by a separate sequence). 

The Figure 15 shows an example of a possible recounting sequence. 
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UE 



MBMS data transfer, PTM 



1 . Notification for re-counting 



UTRAN 



2: RRC connection establisliment/ release 



IVIBIVIS data transfer, PTIVI 



Figure 15: Recounting withi continuation of p-t-m 

In case UTRAN applies re- counting to determine the most optimal transfer mode, the following steps are performed: 

• UTRAN sets the correct MBMS NI and sends the MBMS ACCESS INFORM ATIONincluding service ID, and 
access probability on MCCH 

• Upon DRX wakeup, UEs in idle mode as well as NI- detecting connected mode UEs evaluate the MBMS NI and if 
set, read MCCH at the pre- defined time(s). Upon receiving the MBMS ACCESS INFORMATION including 
access probability, UEs in idle mode for which the probability check passes, initiate RRC connection 
establishment. Connected mode UEs ignore the MBMS ACCESS INFORMATION. 

• UTRAN counts the UEs interested in the MBMS service using UE linking from CN 

• In case a pre- defined threshold is reached, UTRAN continues using the p-t-m transfer mode. Otherwise, UTRAN 
may repeat the MBMS ACCESS INFORMATION a number of times, using different probability values. If the 
threshold is not reached, UTRAN switches transfer mode from p-t-m to p-t-p 

• In case UTRAN continues using the p-t-m transfer mode, it may return UEs that responded to counting back to idle 
mode by releasing the RRC connection. 
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8.1.4 Session Stop 

UTRAN may apply the session stop procedure to inform UEs that the end of MTCH transmission concerns the end of a 
session rather than just an idle period. The purpose of the procedure is to reduce the UE power consumption. 

The Figure 16 shows an example of a possible session stop sequence. 



UE 



UTRAN 



1 . Termination of MBMS data transfer, PTM 



2. Notification for session stop 



Figure 16: Session stop 

In case UTRAN provides the service p-t-m, the session stop sequence involves the following steps: 

• UTRAN sets the correct MBMS NI and provides the SNI 

• Upon DRX wakeup, UEs in idle mode as well as NI detecting connected mode UEsevaluate the MBMS NI and if 
set, read MCCH at the pre- defined time(s) to acquire the required MCCH information. Upon receiving this 
information the UE stops receiving the MTCH 

• Upon detecting the MBMS SNI, SNI- detecting connected mode UEs read MCCH at the pre- defined time(s) to 
acquire the required MCCH information. Upon receiving this information the UE stops receiving the MTCH 

In case UTRAN provides the service p-t-p, the session stop sequence involves the following steps: 

• UTRAN releases the p-t-p radio bearers and updates MCCH (MBMS SERVICE INFO) to inform UEs joining 
or entering the cell at a later point in time. 

8.2 MBMS RNC Signalling Flows 
8.2.1 IVIBMS Session Start procedure 



RNC 






CN 




^ [F 


^ANAP] MBMS SESSION STAF 


^T 








^ REQUEST 

[RANAP] IVIBMS SESSION START ^ 








RESPONSE 




w 





Figure 17: iVIBiVIS Session Start procedure. Successful operation. 

The MBMS Session Start procedure is initiated by the CN when an MBMS Session is started. The MBMS SESSION 
START REQUEST is typically sent by a CN node to RNCs hosting at least one UE that has joined the MBMS Service 
(in case of lu-flex the RNC may receive more than one MBMS SESSION START REQUEST message). 
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The MBMS SESSION START REQUEST contains the MBMS Service Id, the MBMS Session Attributes (MEMS 
Service Area Information, QoS parameters...) It may also include a list of RAs which lists each RA that contains at 
least one PMM-IDLE UE that has activated the service. The MBMS Service Area Information could include MBMS 
Service Areas where UEs have to be tracked (counted), and/or a MBMS Service Areas where this is not required. 

MBMS Session Start procedure also provides the MBMS lu Data Bearer Establishment functionality. If the RNC 
cannot provide resources at all the RNC shall inform the CN accordingly. In case of lu-flex the RNC shall not establish 
more than one MBMS lu bearer for a certain service towards a pool area and shall inform the respective CN nodes 
accordingly. 



8.2.2 MBMS Session Update procedure 



RNC 




CN 




[RANAP] MBMS SESSION UPDATE 






^ REQUEST 

[RANAP] MBMS SESSION UPDATE ^ 








RESPONSE 


w 





Figure 18: MBMS Session Update procedure. Successful operation. 

The MBMS Session Update procedure is initiated by the CN when an MBMS Session is ongoing and SGSN notices 
that there is a need to update the list of RAs. The MBMS SESSION UPDATE REQUEST contains the MBMS Service 
Id, List of RAs with PMM Idle UEs,. . .). 

8.2.3 MBMS Session Stop procedure 



RNC 








CN 






[ 


RANAP] MBMS SESSION STO 


P 










REOUEST 
[RANAPl MBMS SESSION STOP 


^ 










RESPONSE 




w 





Figure 19: MBMS Session Stop procedure. 

This signalling flow depicts the MBMS Session Stop procedure. 

This procedure is initiated by the CN to the RNCs with an ongoing MBMS session, when no more data will be sent for 
that MBMS service for some period of time. 

The MBMS Session Stop procedure also provides the MBMS lu Data Bearer Release functionality. 
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8.2.4 RNC Registration procedure 



RNC 




CN 




[RANAP] MBMS REGISTRATION 






REQUEST ^ 
[RANAP] MBMS REGISTRATION 






^ 


RESPONSE 







Figure 20: MBMS Registration procedure. 

This signalling flow depicts the MBMS Registration procedure. 

This procedure is initiated by the RNC in the case that the RNC is not SRNC for any UE that has joined the MBMS 
Service, but this RNC is DRNC for PMM-CONNECTED UEs that have joined the MBMS Service and there is no 
MBMS Service Context for the MBMS Service in this RNC. 

This procedure shall be initiated by the DRNC, as soon as a UE link is received over the lur and there exists no MBMS 
Service Context for the MBMS service for which the UE link is received. 



8.2.5 RNC De-Registration procedure 



RNC 




CN 




[Ry 


^NAP] MBMS DE-REGISTRAT 


ON^ 






REQUEST 
^ [RANAP] MBMS DE-REGISTRATION 






^ 


RESPONSE 







Figure 21: RNC MBMS De-Registration procedure. 

This signalling flow depicts the RNC De-Registration procedure. This procedure is initiated by the RNC towards the 
CN node it was registered to in case the RNC is not acting as a Serving RNC for any UE that has activated the MBMS 
Service and has ceased to act as a Drift RNC for UEs which has activated an MBMS service. 

8.2.6 CN De-Registration procedure 



RNC 




CN 




4 [R' 


SiNAP] MBMS DE-REGISTRAT 


ON 






^ REQUEST 

[RANAP] MBMS DE-REGISTRATION ^ 








RESPONSE 


w 





Figure 22: CN MBMS De-Registration procedure. 

This signalling flow depicts the CN De-Registration procedure. 

This procedure is initiated by the CN in order to inform the RNC that a certain MBMS Service is no longer available. 
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8.2.7 MBMS Channel Type Switching over Uu 



UE 




CRNC 




SRNC 










MBMS CONTROL (p-t-p) 
















4 

^ 


MBMS DATA (p-t-m) 
MBMS DATA (p-t-m) 








ri 
















CRNC determines to 
switch channel type 
from ptm to ptp 












1 












MBMS Channel Type Reconfiguration Signalling over lur 






[RRC] RB SETUP 






SRNC decides whether to 

perform channel type 

switching to p-t-p or not 
















[RRC] RB SETUP COMPLETE 








M 


MBMS Data (p-t-p) 







Figure 23: Channel type switching signalling flow from p-t-m to p-t-p. 

The CRNC is responsible for the decision regarding having p-t-m transmission or no p-t-m transmission in a cell for a 
specific MBMS service. The CRNC informs all the SRNCs having UEs in that cell about its decision. The SRNC is the 
RNC controlling the RRC connection and RBs to a specific UE. In the example shown, the CRNC decided to no longer 
use p-t-m, then the SRNC decided to perform channel type switching to deliver the MBMS service over DTCH mapped 
on a dedicated channel. The RB SETUP message contains the MBMS Service Id. It is PES whether the SRNC always 
follows the CRNC's request or not. 

NOTE: the channel type switching in this case includes a change of both transport and logical channels. 

8.2.8 MBMS UE Uniting 



SRNC 



CN 



[RANAP] MBMS UE LINKING 
REQUEST 



[RANAP] MBMS UE LINKING 
RESPONSE 



Figure 24: MBMS UE linking signalling flow 

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services. 

The signalling flow is used to link a specific UE to one or several MBMS service contexts in the SRNC. The MBMS 
UE LINKING REQUEST message contains the whole list of MBMS Service Ids activated by the UE. If there has not 
been a MBMS service context related to an MBMS Service Id then SRNC creates a MBMS service context as a result 
of this procedure. 
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8.2.9 MBMS UE De-Linking 



SRNC 



CN 



[RANAP] MBMS UE DE-LINKING 
REQUEST 



[RANAP] MBMS UE DE-LINKING 
RESPONSE 



Figure 25: MBMS UE De-linking signalling flow 

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services. 

The signalling flow is used to remove a specific UE from one or several MBMS service context in the SRNC. The 
MBMS UE DE-LINKING REQUEST message contains the list of MBMS Service Ids de-activated by the UE. 

8.2.10 MBMS Service Id Request 



UE 



RNC 



lu-cs connection establishment 



MSC 



RANAP]COMMON ID 



[RANAPJMBMS SERV CE ID REQ 



[RANAP] MBMS SERVIjCE ID RESPONSE 

< 



SGSN 



Figure 26: MBMS Service Id list over lu signalling flow 

This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The list of MBMS 
services the user has joined is sent over lu. 

The purpose of this signalling flow is to perform UE linking for a RRC connected, PMM idle user. The UE provides an 
indication that the user has joined at least one MBMS service and the PS Domain specific IDNNS (the message that 
would carry this information is FES) whenever an lu-cs connection is established and the UE is PMM idle (that is there 
is no lu-ps connection), The RNC requests the MBMS services the UE has joined from the SGSN (or the SGSN the UE 
is attached to in case of lu-flex) using a connectionless procedure. The MBMS SERVICE ID REQ contains the IMSI of 
the UE. The SGSN response contains the full list of MBMS services the user has joined. 

The MBMS service list is then stored in the RNC. The list is deleted when the UE moves to RRC idle and the RRC 
context is removed in the RNC. 



£75/ 



3GPP TS 25.346 version 6.1.0 Release 6 



35 



ETSI TS 125 346 V6.1.0 (2004-06) 



8.2.1 1 MBMS Attach/Detach over lur 



CRNC 


[RNSAP] MBMS ATTACH 
REQUEST 


SRNC 




^ 








[RNSAP] MBMS ATTACH 
RESPONSE 










w 





Figure 27: MBMS attach request signalling flow: Successful Operation. 

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services. 

The piupose of this signalling flow is 

to either allow the CRNC to add one or several new UEs to the total number of UEs in a given cell using 
one or several MBMS services. The MBMS ATTACH REQUEST then contains the Cell Id of the new 
cell (may contain the URA Id of the new URA for UEs in URA_PCH state), the whole list of affected 
MBMS Service Ids and a UTRAN specific UE Identification if necessary. 

or to allow the SRNC to inform the DRNC in which URA notifications for MBMS Services have to be 
sent. The MBMS ATTACH REQUEST then contains a list of URAs and the corresponding MBMS 
Services. 



CRNC 


[RNSAP] MBMS DETACH 
REQUEST 


SRNC 




^ 








[RNSAP] MBMS DETACH 
RESPONSE 










w 





Figure 28: MBMS detach request signalling flow: Successful Operation. 

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services. 
The purpose of this signalling flow is 

- to either allow the CRNC to decrease the total number of UEs receiving one or several MBMS service in 
a given cell. The MBMS DETACH REQUEST contains the Cell Id of the old cell (may contain the URA 
Id of the old URA for UEs in URA_PCH state), the whole list of affected MBMS Service Ids and a 
UTRAN specific UE Identification if necessary. 

- or to allow the SRNC to inform the DRNC in which URA there is not anymore a need to send 
notifications for MBMS Services due to the presence of UEs in URA_PCH. The MBMS DETACH 
REQUEST then contains a list of URAs and the corresponding MBMS Services 

8.2.12 MBMS Channel Type Reconfiguration over lur 

These signalling flows need further study. 
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[RNSAP] MBMS CHANNEL TYPE 
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[RNSAP] MBMS CHANNEL TYPE 






RECONFIGURATION CONFIRMATION 















Figure 29: Channel Type Reconfiguration signalling flow: Successful Operation. 

This signalling flow is only applicable for handling MBMS UEs in RRC connected mode. 

The purpose of this signalling flow is that the CRNC informs the selected channel type to the SRNCs used in a cell 
under the CRNC. The MBMS CHANNEL TYPE RECONFIGURATION INDICATION contains a list of U-RNTI, 
Channel type and MBMS Service Id corresponding to the UEs connected to the SRNC. It is FFS whether the MBMS 
CHANNEL TYPE RECONFIGURATION INDICATION is initiated when the indicated MBMS Services are delivered 
in p-t-m in CRNC in the session start. 

8.3 MBMS Uu Signalling Flows 

8.3.1 Broadcast of IVIBMS System Information 



UE 



CRNC 



MBMS SYSTEM INFORMATION 



Figure 30: Broadcast of MBMS system information. 

This signalling flow is applicable for handUng MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for UTRAN to broadcast MBMS system information to UEs using the BCCH. The 
MBMS SYSTEM INFORMATION shall be repeatedly transmitted after its first transmission. Upon receiving the first 
MBMS SYSTEM INFORMATION, the UE shall estabUsh the radio bearer carrying an MCCH. 

The MBMS SYSTEM INFORMATION includes: 

- MCCH schedule information (access info, repetition and modification periods) 

- Configuration of a radio bearer carrying an MCCH 

More information may be included in the MBMS SYSTEM INFORMATION. 
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8.3.2 MBMS Service Information 



UE 



CRNC 



MBMS SERVICE INFORMATION 



Figure 31 : MBMS service information signalling flow 

This signalling flow is applicable for handling MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for RNC to inform UEs of all of MBMS services available in one cell. The 
MBMS SERVICE INFORMATION shall be transmitted periodically to support mobility in the MBMS service. 

The MBMS SERVICE INFORMATION contains MBMS service ids and p-t-m indication. The MBMS service ids 
indicate the MBMS services which are being served in the cell or the MBMS services which can be served if the UE 
requests it. P-t-m indication indicates that the MBMS service is on p-t-m in the cell, thus it informs the UE of the need 
of reception of the MBMS RADIO BEARER INFORMATION. More information maybe included in the MBMS 
SERVICE INFORMATION. 

8.3.3 MBMS Radio Bearer Information 



UE 


MBMS RADIO BEARER 
INFORMATION 


CRNC 




^ 








^ 









Figure 32: MBMS radio bearer information signalling flow 

This signalling flow is applicable for handUng MBMS to UEs in IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for the RNC to inform UE(s) regarding the MTCH radio bearer information. 
MBMS RADIO BEARER INFORMATION is only available for p-t-m transmission. MBMS RADIO BEARER 
INFORMATION includes MBMS Service Id, MBMS UTRAN Cell Group Identifier, logical channel, transport channel 
and physical channel information per MBMS service. An MBMS UTRAN Cell Group Identifier is used to indicate to 
UEs which MBMS Cell Group the cell pertains to. More information may be included in MBMS RADIO BEARER 
INFORMATION. 
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8.3.4 MBMS Access Information 



UE 



CRNC 



MBMS ACCESS INFORMATION 



Figure 33: MBMS Access Information signalling flow 

This signalling flow is applicable for handling MBMS UEs in IDLE mode. 

The purpose of the signalling flow is for the RNC to inform UE(s) interested in a particular service of the potential need 
to establish an RRC connection. The MBMS ACCESS INFORMATION includes MBMS service id for each service for 
which counting is required and the associated access "probability factor". More information may be included in MBMS 
ACCESS INFORMATION. 

8.3.5 MBMS Neighbouring Cell Information 



UE 


/IBMS NEIGHBOURING CELL 
INFORMATION 


CRNC 












^ 









Figure 34: MBMS Neighbouring Cell Information signalling flow 

This signalling flow is applicable for handUng MBMS to UEs in PMM IDLE and CONNECTED mode. 

The purpose of the MBMS NEIGHBOURING CELL INFORMATION signalling flow is for the UTRAN to inform to 
UEs of the MTCH configuration of the neighbouring cells which are available for selective combining. With MBMS 
NEIGHBOURING CELL INFORMATION the UE is able to receive MTCH transmission from neighbouring cell 
without reception of the MCCH of that cell. The MBMS NEIGHBOURING CELL INFORMATION shall be 
repeatedly transmitted on MCCH when selective combining is utilized in the MBMS p-t-m transmission in the given 
cell group. 

The usage of MBMS NEIGHBOURING CELL INFORMATION in normal cell reselection case is FES. 

8.3.6 MBMS Joined Indication 



UE 



SRNC 



MBMS JOINED INDICATION 



Figure 35: MBMS joined indication signalling flow 
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This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The MBMS 
JOINED INDICATION is sent over the DCCH. 

The signalling flow is initiated by the UE after entering RRC-Connected, PMM-IDLE state. The purpose of the signalling flow 
is to enable the UE to inform the SRNC that the user has joined at least one MBMS service. The SRNC requests the MBMS 
services the UE has joined from the SGSN as defined in 8.2.10. 



8.3.7 MTCH Scheduling Information 



UE 


MTCH SCHEDULING 
INFORMATION 


CRNC 





















Figure 36: MTCH scheduling information. 

This signalling flow is applicable for handUng MBMS to UEs in PMM IDLE and CONNECTED mode. 

1 . The purpose of the signalling flow is to enable UEs to perform discontinuous reception of MTCH. The UE 
may discontinuously receive MTCH based on scheduling information indicated by the MTCH SCHEDULING 
INFORMATION. This signalling is transmitted on SCCPCH carrying MTCH. The MTCH SCHEDULING 
INFORMATION is signalled at predetermined intervals. The scheduling information allows to cover different 
periods for different MBMS services. 

The MTCH SCHEDULING INFORMATION includes: 

The beginning and duration for possible MBMS service transmissions on this SCCPCH. 



Security for MBMS 



Ciphering for MBMS multicast data is done between the BM-SC and the UE as defined in [7]. Therefore, for MBMS p- 
t-m data transmissions no radio interface ciphering is applied. 

In case of p-t-p MBMS data transmissions, if the security is activated for the UE the ciphering is also applied for p-t-p 
MBMS data RB as for any other RB of the UE. 



1 Mobility Procedures for MBMS 

One of the requirements in [5] is: "Data loss during cell change should be minimal". Therefore, when the UE receiving 
an MBMS session in idle mode or connected mode (not including CELL_DCH) re-selects between cells, it should be 
possible to provide service continuity to this UE. 

The following mechanism has been identified to minimise the data loss on cell change. Additional mechanisms 
allowing to send the MBMS bearer type notification when new mobiles arrive or leave a cell are [FFS]. 

10.1 Use of Periodical IVIBIVIS Channel Type Notification 

In this mechanism, the cell periodically transmits an MBMS Channel Type Notification from the UTRAN, informing 
all MBMS subscribers if it is currently configured for p-t-m transmission or p-t-p transmission. If it is configured for p- 
t-m transmission, the channel may also contain the Radio Bearer parameters corresponding to the TMGI of each 
service. Thus no UE signalling would be required towards the UTRAN. 
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[However, if it is necessary for the UE to instead initiate reception of the RB parameters, such a mechanism similar to 
the Cell Update procedure may be more suitable.] 

If the cell is configured for p-t-p transmission, then the UE would perform a normal RRC connection establishment. 

Additionally, the UE in a cell receiving MBMS p-t-m, could be periodically checking the MBMS Channel Type 
Notification in neighbour MBMS cells to acquire information about whether p-t-m or p-t-p transmission is required if it 
accesses that cell. 



1 0.2 UE Actions for Mobility 



The UE mobility between intra frequency cells is not affected by the MBMS reception. The mobility between different 
frequency layers is affected by the Frequency Layer Convergence process as defined in 11 .2, if used by the network. 

In CELL_FACH and in CELL_DCH state the RRC operation has priority over MBMS reception, thus UE performs the 
inter frequency and inter RAT measurements as configured by the SRNC. UTRAN should utilize different periodicities 
between MCCH transmissions and CELL_FACH state measurement occasion, such that CELL_FACH state 
measurements and MCCH transmissions are not constantly overlapping for some UE. 

In Idle mode and in CELL_PCH, URA_PCH states the measurements are performed as configured by the network 
based on the Release 5. The MBMS specific measurement occasions to S-CCPCH for UEs in idle mode and in 
CELL_PCH, URA_PCH states are not introduced and measurements have priority over MBMS reception. The usage of 
channel protection (channel coding) to recover some of the lost transport blocks is to be checked with RANI. 

UEs may have DRx occasions for specific MBMS service when UE can stop decoding S-CCPCH and perform 
measurements. DRx occasion are based on scheduling information. UE may also have possibility to skip the complete 
MCCH transmission based on e.g. "value tag". 

R99 standards have some means to reduce need for number of measurements, which can be utilized for MBMS. 

When the UE reselects the cell due to the mobility, the UE should check if the interested MBMS service is available in 
the new cell for the reception of the service. The service is available when the session has been already started and the 
service is being served on p-t-p/p-t-m in the cell, or the service can be served in the cell if the UE requests it. 

If the MBMS service is available in the cell, the UE will perform an action for the service reception in the cell. For 
example, if the service is on p-t-p, the idle mode UE will initiate RRC connection establishment procedure. Otherwise, 
the UE does not need to perform such an action in the cell. The UE, which moves to the new cell, will operate 
according to the RRC state/mode as follows. 

Whenever the UE moves between p-t-m cells, UE shall receive an MBMS UCG-Id, which is included in the MBMS 
RADIO BEARER INFORMATION. If the MBMS UCG-Id received in a new cell is the same as the MBMS UCG-Id 
received in an old cell, then the UE receives MTCH without re-establishment of its PDCP as the new cell is processed 
by the same PDCP entity as the old cell. If the MBMS UCG-Ids differs between old on new cell, the UE re-establishes 
its PDCP entity according to the RADIO BEARER INFORMATION. In case that RLC entity is shared in CRNC 
between old and new cell, the UE receives MTCH without re-establishment of its RLC, If old and new cell does not 
share RLC entity in CRNC the UE shall re-establish its RLC. UE shall re-establish MAC and physical layer protocol 
entities upon cell change. 

10.2.1 RRCIdle mode 

Idle mode UE shall: 

if BCCH contains information regarding the MCCH in the new cell: 

- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if the MBMS SERVICE INFORMATION contains the interested MBMS service-id: 
- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else: 
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initiate RRC connection establishment procedure; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MEMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.2 URA_PCH State 

URA_PCH state UE shall: 

perform URA update procedure if needed; 

if BCCH contains information regarding the MCCH in the new cell: 

- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the interested MBMS service id: 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else: 

- initiate cell update procedure 

- if the UE receive the MBMS RADIO BEARER INFORMATION before MBMS SERVICE 
INFORMATION message and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.3 CELL_PCH 

CELL_PCH state UE shall: 

perform cell update procedure; 

if cell update confirm message contains MBMS radio bearer information: 

listen to the MBMS radio bearer; 
else: 

if BCCH contains information regarding the MCCH in the new cell: 

- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the interested MBMS service id and; 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION message and listen to the MTCH 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 
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10.2.4 CELL_FACH 

CELL_FACH state UE shall, depending on UE capability: 
perform cell update procedure 
if cell update confirm message contains MBMS radio bearer information: 

listen to the MBMS radio bearer; 
else: 

if BCCH contains information regarding the MCCH in the new cell: 

- Usten to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the interested MBMS service id and; 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- Usten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.5 CELL_DCH State 

CELL_DCH state UE shall: 

act on the RRC message received on DCCH in handover. 

1 1 Resource Management for MBMS 
11.1 MBMS Access Control Procedure 

MCCH messages initiating counting or recounting cause multiple responses from UEs within a cell. This may result in 
RACH congestion if number of UEs is high in a cell. To avoid this, CRNC may perform MBMS access control 
procedure during counting or recounting procedure. MBMS access control procedure is described in Figure 37. 
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Figure 37: MBMS Access Control Procedure 

1. CRNC calculates an initial probability factor for a MBMS service when a MCCH message causing counting or 
recounting is about to be sent. 

2. CRNC includes the probability factor into the MCCH message and sends it to UEs. This can be done in MBMS 
Group Notification. 

3. UEs perform RRC connection request procedure using the probability factor received in step 2. UEs keep 
listening to MCCH to get updated probability factor until they succeed to establish RRC connection. 

4. CRNC detects the probability factor needs to be updated. Detecting mechanism is not to be standardized. 

5. CRNC recalculates the probability factor. The way of calculating new probability factor is not to be 
standardized. 

6. CRNC includes the updated probability factor into the MCCH message and sends it to UEs. 

7. UEs perform RRC connection request procedure using the new probability factor. UEs keep listening to MCCH 
to get updated probability factor until they succeed to establish RRC connection. 

CRNC and UEs who are still trying to perform the RRC connection request procedure repeat step 3 ~ step 7 until e.g. 
counting or recounting procedure ends. 



1 1 .2 Frequency layer Convergence 



Frequency Layer Convergence denotes the process where the UTRAN requests UEs to preferentially re-select to the 
frequency layer on which the MBMS service is intended to be transmitted. This layer preference could be done by an 
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additional MBMS session related Layer Convergence Information (LCI) such as offset and target frequency. These 
kinds of information could be given to UEs at session start and during the whole session, and will be applied during the 
entire session. More than one offset may be required to support multiple frequencies, but it is assumed that the same 
LCI information will apply to all the services on the same frequencies. 

The details of the mechanism are defined in state 3. 



£75/ 



3GPP TS 25.346 version 6.1.0 Release 6 



45 



ETSI TS 125 346 V6.1.0 (2004-06) 



Annex A (informative): 
MBIVIS Phases in UTRAN 
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Figure 38: Timeline of IVIBMS Service 

The UTRAN MBMS behavior is divided into 3 phases. Figure 14 illustrates the timeline of an MBMS service with 
regards to these phases. 



A1 Security for IVIBIVIS 



A cell stays in phase 1, if there is no ongoing session for the MBMS service, or if it does not belong to the MBMS 
service area of the service. 

A UE that has joined an MBMS service may regularly try to receive MBMS notification in a cell [FFS]. At this phase 
the UE does not request service delivery to UTRAN. 



A2 MBMS Phase 2 



This phase starts when UTRAN receives the MBMS "session start" from CN, and ends when UTRAN initially sets up 
MBMS radio bearer for the session, or decides not to set up the MBMS radio bearer in a cell. 



ETSI 



3GPP TS 25.346 version 6.1.0 Release 6 



46 



ETSI TS 125 346 V6.1.0 (2004-06) 



In this phase, UTRAN transmits notification to UEs about the incoming service and could perform counting procedure 
to decide the type of MBMS radio bearer. UTRAN decides whether to set up p-t-m, p-t-p radio bearer or no radio 
bearer, based on the number of UEs that expected to receive the service in the cell. A UE that has joined a MBMS 
service acts on a RRC message in MCCH. 



A3 MBMS Phase 3 



This phase starts after initial MBMS radio bearer setup and ends when UTRAN receives the MBMS "session stop" 
from CN. 

In this phase, UTRAN transmits the data for the MBMS service received from CN using, if any, the established radio 
bearer. If there is no set-up radio bearer, UTRAN waits for service delivery request from UE. Recounting and radio 
bearer reconfiguration may be performed during this phase. 

UTRAN behavior in this phase can be divided into three states: no transmission, p-t-p transmission, and p-t-m 
transmission. Each cell belonging to the same MBMS service area may be in any of three states. With the variation of 
the number of UEs, the state of a cell may change between the three states. UTRAN may broadcast the state of each 
cell. 

1 ) No Transmission: In this state of a cell, there is no established radio bearer because there is no UE who wants 
to receive the service. An MBMS-joined UE in idle mode that moves into the cell of this state requests service 
delivery to UTRAN. 

2) P-t-p Transmission: In this state of a cell, p-t-p radio bearer is estabhshed. A UE that has joined a MBMS 
service may receive MBMS data over p-t-p radio bearer if there is MBMS data to receive. 

3) P-t-m Transmission: In this state of a cell, p-t-m radio bearer is estabhshed. AUE that has joined a MBMS 
service may receive MBMS data over p-t-m radio bearer if there is MBMS data to receive. 



A4 MBMS Phases and Status Parameters 

Table 1 lists the MBMS parameters that need to be broadcast in each MBMS phase. The list is [EPS] 

Table 1 : MBMS Status Parameters 





Phase 1 


Phase 2 


Phase 3 


Description 


Service ID 


X 


O 


O 


Identity of the Service 


Transmission 
State 


X 


X 


O (NONE/p-t-p/p-t-m) 


State of the cell for MBMS 
transmission 


Counting 


X 


O (On/Off) 


O (On/Off) 


Whether counting procedure is 
going on. 



1 ) Service ID: This parameters indicates is the identity of the service concerned. 

2) Transmission state: This parameter indicates to UE(s) the state of the concerned cell while it is in phase 3. 
According to this parameter, UE entering the cell starts re-configuration of the radio bearer, or requests service 
delivery to UTRAN. Specifically, if this parameter is set to "p-t-m", UE receives service over p-t-m radio bearer 
and if set to "p-t-p", UE receives service over p-t-p radio bearer. If it is set to NONE, UE has to request UTRAN 
to deliver the service. 

3) Counting: Tine counting parameter informs UEs whether counting is required (and is going on) or not. If this 
parameter is set to "ON", UE should perform RRC connection procedure. 
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Annex B (informative): 
MBIVIS Control Information 



Table 2 and 3 identifies MBMS control information and describes their mapping on BCCH, MCCH and DCCH. 

Table 2: Mapping of MBMS Control Parameters in DL 



Information Element 


Description 


DCCH 


BCCH 


MCCH 


MBMS Signalling Radio Bearer Information (MCCH) 


MBMS SRB Info 

- MCCH Indicator 


Information to configure the MBMS 
signalling radio bearer mapped on S- 
CCPCH/FACH, this information 
includes the identification of a FACH 
transport channel carrying the MCCH. 




X 




MBMS Radio Bearer Information (MTCH) 




MBMS RB Info 


Information to configure a p-t-m radio 
bearer mapped on S-CCPCH/FACH for 

transmission of an MBMS service. 






X 


Service related Control Information 




MBMS Service ID(s) 


Identifies all MBMS services that are 
potentially available in one cell (service 
area indication). 

Identifies also the MBMS service related 
to a specific signalling procedure. 






X 


p-t-m Indicator 


Indicates that a p-t-m bearer type is 
established in one cell in order to 
transmit data for a particular MBMS 
service and the UE is required read the 
MBMS RB Info on MCCH. 






X 


RRC Connection 
Establishment Indicator 


Indicates to idle mode UEs that transition 
to RRC connected mode is required for 
counting. 






X 


Required MBMS RB 
configuration 


Indicates to the UE that an MBMS 
service is transmitted using a certain RB 
configuration in order to achieve a 
specific QoS. 






X 


RACH Access 
Probability Factor 


Controls RACH access in order to avoid 
RACH overload if transition to RRC 
connected mode is required. 






X 
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Table 3: Mapping of MBMS Control Parameters in UL 



Information Element 


Description 


DCCH 


Service related Control Information 


MBMS Joined flag 


Indicates that a PMM IDLE state UE in 
RRC connected mode has joined at 
least one MBMS service 


X 
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5.1 .4 Counting where point 8 "The possibility for the RNC to 
receive the service Id in RRC connection request is [FFS]. . . " is 
removed. This reflects to the decision made in RAN2/3AdHoc 
05/03 but was missing from earlier versions, and pointed out by 
RAN WG2 chairman in reflector and in TSG RAN #20. 


2.0.0 


2.1.0 


09/03 


RAN2#37 
RAN3#37 


R2-031713 
R3-031174 
R3-031223 






Editorial corrections based on R2-031713 included. 

New chapter "7. MBMS reception UE Capability" created and 

agreed UE capability text inserted to the new chapter "7.1. UE 

Capability" . 

Modifications based on R3-031 1 74 to the definitions 

Sections 5.1.1, 5.1.5 and 5.1.6 enhanced and sections 5.1.7, 5.1.8 

and 5.1 .9 crated, and signalling flows updated in section 7.1 .based 

onR3-031223 

Following Editorial enhancements proposed by editor: Chapter 
5.3.1.1 and 5.3.1.2 moved to under chapter 6.1. Logical channels 


2.1.0 


2.2.0 
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and chapter "5.4 MBMS Reception in RRC States/Modes" moved 
under chapter 7. in new chapter "7.2 MBMS reception " 






10/03 


RAN2#38 
RAN3#38 


R2-032116 

R2-032074 
R2-032121 

R2-032277 

R2-032087 
R2-032275 
R2-032081 
R2-032281 

R3-031421 






Chapter 5.2. 1 MBMS User Piane Protocol Stack Arctiitecture 

enhanced accordingly. 

Chapter 9 Security for MBMS enhanced accordingly 

Chapter 8.2.2 MBMS service availability enhanced, (message 

changed to information). Chapter 9.2. UE Actions for Mobility 

created and 9.2.4 text depending UE capability \nsene6 

Chapters 8.2.4. MBMS Joined Services Indication and 8.2.5 MBMS 

PMM-Connected State Required Indication created 

Chapters 6.1. re-formatted, Section 6.2.1-6.2.5 created 

The MBMS access control procedure inserted in chapter 11.1 

Broadcast of MBMS System Information signalling flow added. 

Tables inserted to an informative annex to identify MBMS control 

information and describe their mapping on transport channels 

MBMS Time line and MBMS Service announcement definitions 

included in Section 3.1 Chapter 5.1.1 One Context per MBMS 

Service in CRNC and 5. 1.8 RNC deregistration updated 

accordingly 

Editorial harmonization of terms: MCCH and MTCH used 

constantly. (NCCH and CTCH removed) 

In Uu signalling messages CRNC introduced to keep messages 

send/received in SRNC and CRNC inline. 


2.2.0 


2.3.0 


11/03 


RAN2#39 


R2-032350 
R2-032398 
R2-032667 

R2-032666 

R2-032497 






The Signalling flow MBMS service availability changed to MBMS 

service information in 8.2.2. Appropriate changes done in 10.2. 

In the Chapter 7.1. included that MBMS UE must capability to 

receive two SCCPCH 

MBMS notification principles chapter created as 5.1 .5 and RICH 

bits used for MBMS notification defined in 6.2.3 physical channels 

chapters. 

The number of different protocol entities clarified in chapter 5.2.1 . 

The shared PDCP entity principle created in 5.1.4. Protocol layerre- 

establishments due to mobility defined in 10.2. 

UEs measurements are clarified based in working assumption in 

Section 10.2. 

Editorial enhancements to chapter names in chapters 5.1 .1 , 5.1 .2 

and 5.1.3 


2.3.0 


2.4.0 


01/04 


RAN2#40 
RAN3#40 


R2-04086 

Meeting 
report 

R2-040027 
R2-040070 

R3-040061 
R3-040075 
R3-040076 






A chapter 1 1 .2 Frequency layer Convergence introduced based on 

revised text from R2-04086 

Text inserted based on conclusion on selective combining, 

multiplexing and measurement occasions 

Editorial clarifications. Constant usage of MBMS Service Area as 

defined in [4] 

Session stop included 

High level signalling scenarios inserted 

Modification to chapter 5.1 .8 

Modification to RNC registration procedure 

Additional modifications to 5.1.8 
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02/04 


RAN2#41 
RAN3#41 


Meeting 
minutes 
R2-040572 

R2-040690 
R2-04071 1 

R3-040577 
R3-040576 

R3-040314 
R3-040393 

R3-040575 
R3-040458 
R3-040516 

R3-040545 

Meeting 

minutes 






Selective combining, simulcast for TDD, Neighbouring cell info, 

included 

MCCH scheduling, MBMS notification and counting enhanced. 

MBMS access 

MTCH Scheduling information signalling flow included 

MBMS high level signalling scenarios updated 

Editorial clean up, separation of UTRAN architecture principles and 

MBMS Uu principles chapter created 

Functionality to filtering of MBMS notifications and Session update 

signalling flow included 

MBMS Service Id Request to handle UEs in RRC connected PMM 

idle state. The Signalling flow MBMS Joined Indication modified 

and MBMS PMM connected stated required removed. 

FFS removed from RNC De-Registration and CN De-Registration 

Clarifications to MBMS lu bearer and MBMS Session Start and 

Session Stop and CN De-Registration 

UE linking over lur modified according agreements 

Clarification to creation of MBMS Service context after receiving the 

first UE linking 

Editorial clean up to RAN3 specific sections. 

The lub bearer mechanisms defined. 

Editorial enhancements based on comments after email review on 
RAN 1/2/3 reflectors. 


2.5.0 


2.6.0 


03/2004 


RAN#23 


RP-040079 






Upgrade towards Change Control (Release 6) and ETSI MCC 
clean-up. 


2.6.0 


6.0.0 


06/2004 


RP-24 


RP-040216 


001 




Updates based on the MBMS ad-hoc, Budapest, 20-22 April 2004 


6.0.0 


6.1.0 




RP-24 


RP-040216 


002 




Updates to TS25.346 from the RAN3#42 meeting in Montreal, 
Canada, 10-1 4 May 2004 
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